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1.0  SCOPE 
1 .1  Identification 

— This  specification  establishes  the  requirements  for  the 
Test  Program  function  of  the  IDAMST  System.  The  Operational 
consists  of  two  primary  programs,  referred  to  as  Ground  Test 
(GTP-1)  and  Ground  Test  Program  No.  2  (GTP-2). 


Operational 
Test  Program 
Program  No.  1 


1 .2  Functional  Summary 

—''The  paragraphs  below  describe  the  IDAMST  specifications  for  the  Opera¬ 
tional  Test  Programs.  These  computer  programs  will  be  executed  in  the  IDAMST 
avionics  processors  in  order  to  determine  the  operational  readiness  of  the 
IDAMST  core  elements  and  avionics  subsystems,  to  display  the  equipment  status 
to  the  ground  operator  and  to  initialize  tables  which  describe  equipment 
status.  _ 


2.0  APPLICABLE  DOCUMENTS 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this 
specification  to  the  extent  specified  herein.  In  the  event  of  conflict 
between  the  documents  referenced  herein  and  the  contents  of  this  specifica¬ 
tion,  the  contents  of  this  specification  shall  be  considered  a  superseding 
requirement. 

Specifications: 

1)  Computer  Program  Development  Specification  for 
IDAMST  Operational  Flight  Program  Executive 
Software  -  Type  B5,  30  July  1976 

Other  Publications: 

1)  Appendix  G  to  Statement  of  Work  for  Purchase  Request 
FV  11757600271  LTP  Function  Requirement  Specificaiton. 

2)  Specifications  for  IDAMST  Software  Final  Technical 
Report  -  MDC  Report  J 7271  -  30  July  1976 
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3.0  REQUIREMENTS 

The  program  GTP-1  will  interface  with  the  IDAMST  core  elements: 
processors,  Bus  Control  Interface  Units  (BCIU's),  Multiplex  Bux  (MUX), 

Remote  Terminals  (RT's),  controls  and  displays  and  mass  memory. 

The  function  of  GTP-1  is  to  test  the  performance  of  these  core  elements, 
detect  any  malfunctions,  isolate  the  fault  to  the  lowest  LRU  level,  and 
display  the  test  results  on  the  cockpit  displays  to  the  maintenance  crew. 

Similarly,  the  function  of  the  GTP-2  is  to  test  the  performance  of  the 
IDAMST  Avionics  Subsystems  Suite,  detect  any  malfunctions,  isolate  the  fault 
to  the  lowest  LRU  level  and  display  the  test  results  on  the  cockpit  displays 
to  the  maintenance  crew. 

Technician  interaction  for  manipulating  controls  and  verifying  display 
presentations  will  be  required  to  perform  these  tasks. 

3. 1  Computer  Program  Definition 

The  programs  GTP-1  and  GTP-2  will  be  stored  on  magnetic  tape  and  read 
into  the  processor  memories.  These  programs  will  be  read  sequentially  into 
the  processor  memories  and  executed  whenever  failures  are  suscepted  in  the 
system  or  when  a  complete  test  is  desired  in  preparation  of  the  aircraft  for 
a  mission. 

After  the  system  has  been  energized,  the  ROM  Start-Up  Program  is  respon¬ 
sible  for  process  initialization  and  selection  of  the  master  and  monitor 
processors.  The  Master  Executive  Program  is  then  loaded  into  the  Master 
Processor.  The  Master  Processor  will  proceed  with  the  loading  of  the  proces¬ 
sors,  initialize  the  system  and  initiate  normal  system  operation.  If  one  of 
the  test  programs  is  requested,  the  Master  Executive  Program  will  cause  that 
Program  to  be  read  from  magnetic  tape  into  the  Master  Processor  and  initiate 
its  execution  by  invoking  the  Test  Master  Sequencer. 

The  loading  of  a  test  program  will  be  initiated  by  means  of  the  Processor 
Control  Panel  which  will  contain  a  switch  allowing  the  operator  to  choose 
between  the  Application  Program,  GTP-1  and  GTP-2. 
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When  a  test  program  has  been  loaded,  a  message  requesting  the  operator 
to  choose  a  -est  sequence  will  appear  on  MPD-1  and  a  checklist  will  be  dis¬ 
played  on  the  IMK.  During  the  course  of  the  testing,  instructions  and 
status  messages  will  be  displayed  on  the  PMD-1. 

The  operator  will  indicate  that  he  wishes  either  the  normal  sequence  of 
tests  or  specific  tests  by  depressing  a  switch  on  the  IMK.  If  specific  tests 
are  requested,  the  DEK  will  be  activated  and  the  operator  will  write  in  the 
code  for  the  first  test  desired. 

As  each  test  is  finished,  a  test  complete  message  will  appear  on  the 
MPD-1.  If  further  tests  are  desired,  the  operator  will  indicate  successive 
tests  by  using  the  DEK  to  write  the  test  code. 

When  an  LRU  is  determined  to  be  faulty,  this  information  will  be  dis¬ 
played  to  the  ground  crew.  The  test  programs  will  also  store  all  indications 
of  faulty  LRU's  in  a  status  matrix.  This  matrix  will  be  displayed  to  the 
ground  crew  on  the  completion  of  any  test  sequence. 

The  GTP-1  and  GTP-2  software  will  also  manage  display  messages  requesting 
ground  crew  cooperation  in  operating  controls  and  in  verifying  responses. 

3.2  Detailed  Functional  Requirements 
3.2.1  GTP-1  Program 

The  GTP-1  Software  will  consist  of  three  System  Control  Modules,  seven 
first  level  testing  tasks  and  SPECs,  DISPs  and  EQUIPS  as  shown  in  Figure  1. 

Test  System  Control  Modules  include  the  Test  Master  Sequencer,  Test 
Request  Processor  and  Test  Controller.  These  top  level  controllers  on  a 
hierarchical  control  tree  are  responsible  for  initializing  and  controlling 
the  test  tasks.  The  Test  Master  Sequencer  initializes  the  compools  and 
schedules  the  other  two  system  control  modules. 

When  the  ground  crew  operator  requests  a  test  or  a  series  of  tests,  the  par¬ 
ticular  EQUIP  servicing  the  controls  and  displays  will  set  the  Test  Request 
Processor  event  causing  the  Test  Request  Processor  module  to  be  activated. 

The  Test  Request  Processor  determines  whether  a  test  request  is  acceptable 


TEST 

MASTER 

SEQUENCER 


Figure  1  GTP-1  Overview 


at  this  stage  of  the  processing.  A  request  is  not  acceptable  if  it  will 
interfere  with  the  test  in  progress. 

If  the  request  is  acceptable,  the  Test  Request  Processor  activates  the 
Test  Controller  for  processing  the  request.  The  Test  Controller  initially 
schedules  all  lower  level  tasks.  It  activates  each  testing  task  either  in 
its  normal  sequence  or  when  specifically  requested  by  the  operator. 

The  normal  test  sequence  is  as  follows: 

1)  Processor  Test  Task  to  Test  Master  Processor 

2)  BCIU  Test  Task  to  Test  Master  BCID 

3)  RT-Bus  Test  Task  to  test  all  RTs  and  Buses 

4)  BCIU  Test  Task  to  test  other  BCIUs 

5)  Processor  Test  Task  to  test  all  other  Processors 

6)  Electronics  Test  Task  to  test  display  electronics 
(MPDGs ,  DSMU,  MDSC  and  Displays) 

7)  Switch  Test  Task  to  test  all  display  switches 

8)  Display  Test  Task  to  test  MPDGs  and  bus,  refresh  memories, 
displays  and  switching  matrix 

9)  Mass  Memory  Test  Task  to  test  Mass  Memory 

Failure  information  will  be  displayed  on  MPD  either  as  a  message  or  in 
the  status  matrix.  The  status  matrix  will  indicate  the  "go/no-go"  status  of 
the  following: 

3  Processors 
6  (3  redundant)  BCIUs 

12  (6  redundant)  RTs 

2  Buses 

2  MPDGs 

Bus  between  MPDGs 
DSMU 

Switching  Matrix 
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5  Refresh  Memories 

3  MPDs 

2  HUDs 

2  HSDs 

2  DEKs 

2  IMFKs 

Mass  Memory 

Built-in  Test  Equipment  (BITE)  will  be  used  in  testing  processors,  BCIUs, 
RTs  and  Control /Display  Electronics.  In  many  cases,  this  equipment  will 
indicate  only  an  overall  go/no-go  status.  However,  the  electronics  equipment 
has  a  Fault  Isolation  Test  (FIT)  capability  and  the  other  components  have 
self- test  software  supplied  by  the  manufacturer.  These  capabilities  will  be 
used  to  indicate  failures  of  lower  level  components. 

3.2. 1.1  Test  Master  Sequencer 

The  Test  Master  Sequencer  is  the  highest  level  system  control  in  the 
GTP-1  software.  It  is  initiated  by  the  Master  Executive  module  after  start-up 
is  completed.  It  processes  the  data  initialization  and  schedules  the  Test 
Request  Processor  and  the  Test  Controller. 

Computer  requirements  for  the  module  are: 


Memory  Size 

10 

16  bi t  words 

Throughput 

54 

ms/sec 

Update  Rate 

N/A 

times/sec 

3.2. 1 . 1 . 1  Inputs 

There  are  no  inputs  to  the  Test  Master  Sequencer. 

3.2.1 .1 .2  Processing 

The  Test  Master  Sequencer  processing  is  shown  in  Figure  2  . 

Upon  initial  startup  of  the  GTP-1  as  commanded  by  the  Executive  Program,  the 
Test  Master  Sequencer  schedules  the  Test  Request  Processor  and  the  Test 
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SCHEDULE: 

TEST  REQUEST  j 
PROCESSOR,  TEST1 


SIGNAL  TEST  I 
CONTROLLER  ! 
INITIAL  EVENT  | 


Figure  2  Test  Master  Sequencer 
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Controller.  The  Test  Controller  Initialization  Event  is  turned  on  so  that 
the  Test  Controller  can  initialize  compools. 


3. 2. 1.1. 3  Outputs 

The  outputs  from  the  Test  Master  Sequencer  shall  be  as  shown  in 

Table  I. 

3. 2. 1.2  Test  Request  Processor 

The  Test  Request  Processor  interprets  inputs  from  the  display  indi¬ 
cators.  It  determines  whether  an  input  from  the  DMK  is  a  test  response  or  a 
request  to  change  the  test  sequence.  In  the  latter  case,  it  signals  the 
Test  Controller  to  process  the  request. 

Computer  requirements  for  the  module  are: 


Memory  Size 

44 

16  bit  words 

Throughput 

276 

ms/sec 

Update  Rate 

N/A 

times/sec 

3. 2. 1.2.1  Inputs 

The  inputs  to  the  Test  Request  Processor  shall  be  as  specified  in 

Table  II. 

3.2. 1.2. 2  Processing 

The  Test  Request  Processor  shall  perform  the  processing  specified 
in  Figure  3. 

The  Test  Request  Processor  determines  from  Test  Controller  flags 
which  test  is  in  progress.  If  a  DMK  indicator  is  to  be  processed  either  the 
Switch  Test  Task  or  the  Controls  Test  Task  is  signalled  to  continue  processing 
if  either  was  in  progress.  Otherwise,  the  Test  Controller  is  signalled  to 
process  a  test  series  change.  If  the  indicator  was  not  on  the  DEK,  then 
either  the  Display  Test  Task  is  signalled  to  continue  processing  or,  the 
Switch  Test  Task  is  signalled  to  continue. 
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TABLE  I  OUTPUTS  FROM  TEST  MASTER  SEQUENCER 


Figure  3  Test  Request  Processor 


3. 2. 1.2. 3  Outputs 

The  outputs  from  the  Test  Request  Processor  shall  be  as  specified 
in  Table  III. 

3. 2. 1.3  Test  Control ler  (GTP-1) 

The  Test  Controller  is  activated  to  initiate  testing,  when  there  is 
a  request  for  a  change  in  test  sequence  and  after  each  test  is  completed. 

It  controls  the  scheduling  of  tests.  The  normal  sequence  is: 

Master  Processor 
Master  BCIU 
RT  &  MUX  (All) 

Other  BCIU’ s 
Other  processors 

Electronic  Controls  (MPDG's,  DSMU,  MDSC  and  displays) 

Swi tches 

Displays  (MPDG,  displays;  refresh  memory,  bus,  switching 
matrix) 

Mass  Memory 

Computer  requirements  for  the  module  are: 


Memory  Size 

137 

16  bi t  words 

Throughput 

499 

ms/sec 

Update  Rate 

N/A 

times/sec 

3. 2. 1.3.1  Inputs 

The  inputs  to  the  Test  Controller  shall  be  as  specified  in  Table  IV. 


3. 2.1'.  3. 2  Processing 

The  Test  Controller  shall  perform  the  processing  specified  in  Figure 
4.  Data  initialization  at  startup  is  signalled  by  the  Startup  Flag  set  in 
the  Test  Master  Sequencer.  This  data  initialization  is  performed  by  setting 
the  initialization  flags  in  all  the  modules  requiring  initialization  and 
scheduling  these  modules.  Also,  all  the  EQUIP’ s  and  DISP’s  are  scheduled. 
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TABLE  HI  OUTPUTS  FROM  TEST  REQUEST  PROCESSOR 


TABLE  IV  INPUTS  TO  THE  TEST  CONTROLLER 
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rest  Controller 


The  Test  Controller  signals  a  DISP  event  requesting  the  ground  crew  to  choose 
a  test  sequence. 

The  initiation  of  a  test  sequence  or  a  change  in  one  is  signalled 
by  the  Test  Request  Processor.  Changes  in  the  test  sequence  can  occur  anytime 
except  during  the  processing  of  the  Switch  Test  Task  or  the  Controls  Test 
Task.  If  the  request  is  for  a  change,  all  tasks  are  terminated  and  the  dis¬ 
plays  are  cleared.  To  start  the  new  sequence,  the  Test  Controller  signals 
the  appropriate  task.  Test  status  data  includes  the  test  sequence  and  the 
task  being  processed. 

When  a  test  is  completed,  the  Test  Controller  waits  until  the 
ground  crew  has  read  the  status  matrix  and  then  clears  the  display.  If  there 
are  more  tests  in  the  sequence,  the  Test  Controller  determines  from  the  test 
status  the  next  test  and  signals  the  appropriate  task.  If  the  test  sequence 
is  completed,  the  Test  Controller  signals  the  displays  to  turn  off  the  IMK 
light,  to  display  the  status  matrix  and  to  display  a  "tests  complete"  state¬ 
ment. 


3.2.1 .3.3  Outputs 

The  outputs  from  the  Test  Controller  shall  be  as  specified  in 

Table  V. 


3. 2. 1.4  Processor  Test  Task 

The  Processor  Test  Task  is  activated  twice  during  the  normal  test 
sequence.  It  is  first  activated  to  test  the  Master  Processor  and  Master 
Processor  Memory  and  later  to  test  all  other  processors  and  processor 
memories. 


Computer  requirements  for  the  module  are: 


Memory  Size 

67 

16  bit  words 

Throughput 

436 

ms/sec 

Update  Rate 

N/A 

times/sec 
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TABLE  V  OUTPUTS  FROM  TEST  CONTROLLER 


3. 2. 1.4.1  Inputs 

The  inputs  to  the  Processor  Test  Task  shall  be  as  specified  in 

Table  VI. 

3. 2. 1.4. 2  Processing 

The  Processor  Test  Task  shall  perform  the  processing  as  specified 
in  Figure  5. 

It  is  first  determined  whether  the  task  was  enabled  to  test  only 
the  Master  Processor.  Otherwise,  the  software  must  test  all  the  other 
processors. 


The  BIT  (Built-In  Test)  data  will  be  checked.  This  is  done  by 
invoking  the  executive  task  that  requests  this  data.  BIT  data  will  include 
such  information  as: 

Computer  clock  malfunction 

Overtemp  condition 

Arithmetic  overflow 

Attempted  memory  protect  violation 

Power  interrupt 

Memory  parity  error 

If  there  is  not  a  response  on  the  specified  time,  this  will  be 
displayed  for  the  operator  by  signalling  a  DISP  event.  Otherwise  the  BIT 
data  is  stored  for  evaluation. 

A  series  of  self-tests  will  complete  the  processor  testing.  It 
is  assumed  that  the  software  for  these  tests  will  be  supplied  with  the  hard¬ 
ware.  These  tests  will  include  such  information  as: 

/ 

Arithmetic  self-test 

Memory  read/write  and  memory  addressing  test 
Processor/BCIU  program  control  I/O  and  DMA  I/O  test 
1 1  irrupt  tests 

Read/write  from  each  general  register 
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TO  PROCESSOR  TEST  TASK 


Figure  5  Processor  Test  Tdsk 


If  a  response  is  not  received  in  the  specified  time,  a  DISP  event 
will  be  signalled  to  display  the  time-out  for  the  operator. 

After  all  processors  have  been  tested,  a  SPEC  event  will  be  sig¬ 
nalled  to  evaluate  the  data.  The  status  of  each  processor  will  be  stored  in 
the  status  matrix.  The  matrix  will  be  displayed  for  the  operator. 

The  task  then  signals  the  Test  Controller  that  the  test  has  been 

completed. 


The  path  used  in  testing  the  processors  other  than  the  Master 
Processor  will  be  one  previously  determined  to  be  operational.  In  the  normal 
test  sequence  these  processors  will  be  tested  after  the  BCIUs,  RTs,  and  buses. 

3. 2. 1.4. 3  Outputs 

The  outputs  from  the  Processor  Test  Task  shall  be  as  specified  in 

Table  VII. 

3. 2. 1.5  BCIU  Test  Task 

The  BCIU  Test  Task  is  activated  twice  during  the  normal  test 
sequence.  On  its  first  activation  it  will  test  the  Master  BCIU.  After  the 
RT-Bus  Test  Task,  it  will  again  be  activated,  this  time  to  test  all  non- 
Master  BCIUs.  In  testing  these  non-Master  BCIUs,  a  path  that  has  been  deter¬ 
mined  to  be  operational  will  be  used. 

Computer  requirements  for  the  module  are: 

Memory  Size  73.  16  bit  words 

Throughput  436  ms/sec 

Update  Rate  N/A  times/sec 

3.2.V.  5.1  Inputs 


The  inputs  to  the  BCIU  Test  Task  shall  be  as  specified  in  Table 


OUTPUTS  FROM  PROCESSOR  TEST  TASK 
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3. 2. 1.5. 2  Processing 

The  BCIU  Test  Task  shall  perform  the  processing  specified  in 

Figure  6. 


It  is  first  determined  whether  the  Master  BCIU  or  all  other  BCIUs 
is  being  tested.  In  the  latter  case  one  BCIU  will  be  tested  at  a  time. 

The  executive  task  uses  the  Mode  Message  to  obtain  both  BIT  and 
self- test  data.  The  BCIU  Test  Task  will  first  request  the  executive  to 
obtain  BIT  data.  If  a  response  is  not  received  in  the  specified  time,  a 
time-out  error  will  be  displayed  for  the  operator.  This  will  be  done  by 
signalling  a  DISP  event. 

If  the  data  is  received  it  is  stored  for  evaluation.  The  data 
will  include: 


Message  Error  checks  for  both  transmitter  and  receiver,  no 
data  received,  incomplete  data,  data  parity  error,  or 
invalid  command 

Power  interrupt  condition  occurred 
DMA  Error  Condition 
Invalid  Instruction 

The  Mode  Message  is  used  to  request  the  BCIUs  to  perform  self¬ 
tests.  For  GTP-1,  these  tests  should  be  complete.  That  is,  every  control 
path,  every  instruction,  every  register,  etc.,  should  be  tested  not  some 
subset  of  each.  The  self- test  software  should  be  prepared  along  with  the 
hardware  and  will  include  tests  such  as: 

Data  flow  tests 

/ 

Loading/ reading  internal  registers 
Sequence  and  control  tests 
Internal  bi-directional  bus  tests 
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Closed  loop  or  wrap  around  test  of  bus  channels 
DMA  data  flow  and  PI/0  operation  checks 

If  a  response  is  not  received  in  the  specified  time,  the  time-out 
error  will  be  displayed  for  the  operator. 

After  every  BCIU  has  been  tested,  the  data  will  be  evaluated  by 
signalling  a  SPEC  event.  If  any  half  of  a  BCIU  has  an  error,  that  half  will 
be  declared  a  failure.  However,  if  every  BCIU  on  a  bus  appears  to  be  a 
failure,  then  the  bus,  not  the  BCIUs,  will  be  declared  a  failure. 

The  results  of  the  evaluation  will  be  written  in  the  status  matrix 
which  will  be  displayed  for  the  operator. 

The  task  will  then  signal  a  Test  Controller  event  that  the  tests 
have  been  completed. 

3. 2. 1.5. 3  Outputs 

The  outputs  from  the  BCIU  Test  Task  shall  be  as  specified  in 

Table  IX. 


3. 2. 1.6  RT-Bus  Test  Task 

The  RT-Bus  Test  Task  is  activated  during  the  normal  test  sequence  or 
when  the  RT-Bus  tests  are  specifically  requested  by  the  ground  crew. 

Computer  requirements  for  the  module  are: 

Memory  Size  80  16  bit  words 

Throughput  383  ms/sec 

Update  Rate  N/A  times/sec 

3. 2. 1.6.1  Inputs 

The  inputs  to  the  RT-Bus  Test  Task  shall  be  as  specified  in  Table  X. 
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INPUTS  TO  RT-BUS  TEST  TASK 


3. 2. 1.6. 2  Processing 


The  RT-Bus  Test  Task  shall  perform  the  processing  as  specified  in 

Figure  7. 


The  RT-Bus  Test  Task  shall  test  all  of  the  RTs  on  one  bus.  If  all 
RTs  fail  then  the  bus,  not  the  RTs,  will  be  declared  a  failure.  The  task 
shall  then  test  all  RTs  using  the  other  bus. 

Each  half  of  an  RT  will  be  tested  first  using  BIT  data.  The  BIT 
data  is  obtained  by  sending  a  Command  Mode  Message  to  the  Executive  Task. 

The  BIT  data  shall  include: 

Message  error  checks,  no  data  received,  incomplete  data, 
data  parity  error  or  invalid  command 

Power  interrupt  condition  occurred 

Wrap  around  data  check  on  last  word 

Parity  checks  and  adknowledgement  checks  in  Interface 
Module  (IM) 

If  a  response  is  not  received  in  the  specified  time  a  time-out 
error  will  be  displayed  for  the  operator. 

A  Command  Mode  Message  is  sent  to  the  Executive  Task  requesting 
that  complete  self-tests  be  performed.  These  tests  include: 

General  RT  closed  loop  or  wrap  around  tests 

Data  flow  tests 

Sequence  and  control  tests 

Internal  bi-directional  bus  tests 

'  Analog  to  digital  converter  calibration  checks 

Tolerance  check  on  each  supply  voltage 

Interface  Module  (IM)  Tests  as  follows: 
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Figure  7  RT  Bus  Test  Task 


IM 


Check 


Cal  check  Each  Chennel 
Wrap  Feedback  Compare 
Dual  Demodulation  &  Compare 
Selective  Demodulation  of 
Each  Channel 
Reasonableness  Test  on 

Sin2  +  cos2  =  Constant 
Wrap  Compare  Input  and 
Output  Logic 

If  a  response  is  not  received  in  the  specified  time,  a  time-out 
error  will  be  displayed  for  the  operator. 

When  tests  have  been  completed  for  all  RTs  and  both  buses,  the 
data  is  evaluated.  A  SPEC  event  is  signaled.  This  SPEC  will  determine  if  a 
bus  has  galled,  and  if  not  will  determine  which  RTs  shall  be  declared 
failed.  This  data  is  written  in  the  Status  Matrix  which  is  displayed  for 
the  operator. 

The  task  will  signal  the  Test  Controller  that  the  tests  have  been 

completed. 

3. 2. 1.6. 3  Outputs 

The  outputs  from  the  RT-Bus  Test  Task  shall  be  as  specified  in 

Table 


DC  Analog  Input 
Discrete  Output 
AC  Analog  Input 
AC  &  Synchro  Analog 
Output 
Synchro  Input 

Serial  &  Special  I/O 


3. 2. 1.7  Electronics  Test  Task 

The  Electronics  Test  Task  is  activated  during  the  normal  test 
sequence  or  when  it  is  specifically  requested  by  the  ground  crew.  The  task 
tests  the  electronics  of  the  Control  and  Display  system  including  two  Modular 
Programmable  Display  Generators  (MPDG) ,  the  Display  Switch/Memory  Unit  (DSMU), 
the  Modular  D.gital  Scan  Converter  (MDSC)  and  displays. 
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OUTPUTS  FROM  RT-BUS  TEST  TASK 


Computer  requirements  for  the  module  are: 


Memory  Size 

47 

16  bit  words 

Throughput 

31_2 

ms/sec 

Update  Rate 

'ilA 

times/sec 

3. 2. 1.7.1  Inputs 

The  inputs  to  the  Electronics  test  Task  shall  be  as  specified  in 

Table  XII. 

3. 2. 1.7. 2  Processing 

The  Electronics  Test  Task  shall  perform  the  processing  specified 
in  Figure  8. 

BIT  shall  be  requested  by  sending  a  Command  Mode  Message  to  the 
Executive  Task.  In  this  case,  BIT  is  used  to  determine  an  overall  "go/no-go" 
status.  If  a  system  "go"  response  is  received,  that  information  is  displayed 
for  the  operator  and  used  to  update  the  status  matrix. 

If  either  a  "no-go"  is  received  or  a  response  is  not  received  in 
the  specified  time,  the  Fault  Isolation  Test  (FIT)  capability  is  needed.  FIT 
is  used  on  the  ground  to  determine  which  module  has  failed.  It  is  requested 
by  use  of  the  Command  Mode  Message  to  the  Executive  Task.  If  a  response  is 
not  received  in  the  specified  time,  a  time-out  error  will  be  displayed  for 
the  operator. 

If  a  response  is  received,  the  module  failures  will  be  displayed 
for  the  operator  and  the  status  matrix  will  be  updated. 

The  task  will  signal  the  Test  Controller  that  the  tests  have  been 

completed. 

3. 2. 1.7. 3  Outputs 

The  outputs  from  the  Electronics  Test  Task  shall  be  as  specified 
in  Table  XIII. 
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TABLE  XII  INPUTS  TO  ELECTRONICS  TEST  TASK 


OUTPUTS  FROM  ELECTRONICS  TEST  TASK 
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3. 2. 1.8  Switch  Test  Task 


The  Switch  Test  Task  is  activated  during  the  normal  test  sequence  or 
when  it  is  specifically  requested  by  the  ground  crew.  The  task  tests  all 
display  light  switches. 


Computer  requirements 

for  the 

module  are: 

Memory  Siz^ 

80 

16  bit  words 

Throughput 

472 

ms/sec 

Update  Rate 

m 

times/sec 

3. 2. 1.8.1  Inputs 

The  inputs  to  the  Switch  Test  Task  shall  be  as  specified  in  Table 

XIV. 

3.2. 1.8.2  Processing 

The  Switch  Test  Task  shall  perform  the  processing  specified  in 

Figure  9. 


It  is  assumed  that  the  ground  crew  can  determine  faulty  light 
bulbs  by  inspection.  That  is,  if  no  light  is  turned  on  before  a  failure 
message  arrives,  the  bulb  should  be  replaced  and  the  switch  retested. 

To  avoid  confusion,  the  test  sequence  can  not  be  changed  while 
this  task  is  processing.  The  Test  Request  Processor  shall  route  all  switch 
data  to  the  Switch  Test  Task  rather  than  the  Test  Controller. 

The  task  will  signal  a  DISP  event  to  display  instructions  to  the 
operator.  The  operator  will  be  requested  to  depress  each  switch  as  it  is 
lighted.  These  include: 

'  15  switches  on  MMP,  light  turned  from  white  to  green 

7  top  switches  on  IMK-1,  light  turned  from  white  to  green 
10  side  switches  on  IMK-1,  light  turned  from  white  to  green 
7  top  switches  on  IMK-2,  light  turned  from  white  to  green 
10  side  switches  on  IMK-2,  light  turned  from  white  to  green 
12  switches  on  DEK-1,  light  turned  ON  (white) 
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TEST  TASK 


Figure  9  Switch  Test  Task 


12  switches  on  DEK-2,  light  turned  ON  (white) 


Each  light  will  be  turned  on.  If  a  response  is  not  received  in 
the  specified  time,  the  switch  failed  the  test  and  this  will  be  displayed. 
If  the  wrong  switch  was  pressed,  another  test  will  be  performed  for  that 
switch.  If  the  switch  is  still  in  error,  the  switch  will  be  declared 
fai led. 


The  status  matrix  shall  be  updated  after  all  switches  have  been 
tested.  It  will  be  displayed  by  signalling  a  DISP  event. 

The  task  will  signal  the  Test  Controller  that  the  tests  have  been 

completed. 

3.2. 1.8.3  Outputs 

The  outputs  from  the  Switch  Test  Task  shall  be  as  specified  in 

Table  XV. 

3. 2. 1.9  Display  Test  Task 

The  Display  Test  Task  is  activated  during  the  normal  test  sequence 
or  when  it  is  specifically  requested  by  the  ground  crew.  This  task  will 
test  the  two  MPDGs  and  bus,  the  refresh  memories,  the  displays  and  the 
switching  matrix. 

Computer  requirements  for  the  module  are: 


Memory  Size 

232 

16  bit  words 

Throughput 

775 

ms/sec 

Update  Rate 

N/A 

times/sec 

3. 2. 1.9.1  Inputs 

/ 

The  inputs  to  the  Display  Test  Task  shall  be  as  specified  in 

Table  XVI. 
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TABLE  XV  OUTPUTS  FROM  SWITCH  TEST  TASK 


TABLE  XVI  INPUTS  TO  DISPLAY  TEST  TASK 


'S 


3. 2. 1.9. 2  Processing 

The  Display  Test  Task  shall  perform  the  processing  specified  in 

Figure  10. 


The  ground  crew  operator  shall  determine  whether  a  display  is 
operational  or  a  failure.  The  task  will  turn  on  a  specific  switch  every 
time  a  new  test  decision  is  to  be  made.  Two  switches  will  be  used  by  the 
operator:  one  to  indicate  an  operational  display,  the  other,  a  failure. 

This  test  should  follow  the  Switch  Test  Task  so  that  switches  can  be  assumed 
in  working  condition. 

The  BITE  signals  for  the  MPDGs  have  already  been  tested.  One  of 
the  MPDGs  will  be  requested  to  display  a  special  test  pattern  on  the  MPD-1 . 

If,  for  any  reason,  the  display  is  a  failure,  the  failure  will  be  displayed 
for  the  operator. 

If  the  display  is  operational,  the  test  pattern  will  be  repeated 
using  different  refresh  memories  to  test  the  refresh  memories.  The  test 
pattern  will  then  be  switched  to  the  other  MPDG.  The  same  processing  will  be 
done  for  this  MPDG. 

The  displays  (2  HUDs,  2  HSDs,  and  3  MPDs)  will  be  tested  next.  A 
TV  type  test  pattern  will  be  displayed.  It  will  be  rotated  and  switched  from 
display  to  display.  The  operator  will  indicate  which  displays  are  operational. 

A  SPEC  event  will  be  signaled  to  evaluate  the  equipment.  This 
SPEC  will  analyze  the  failures  to  determine  which  equipment  is  faulty.  The 
Status  Matrix  will  be  updated  and  displayed  for  the  operator. 

The  task  will  signal  the  Test  Controller  that  the  tests  have  been 

completed. 

3. 2. 1.9. 3  Outputs 

The  outputs  from  the  Display  Test  Task  shall  be  as  specified  in 
Table  XVII. 
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SIGNAL  EQUIP 


Figure  10  Display  Test  Task  ( Cont . 


TABLE  XVII  OUTPUTS  FROM  DISPLAY  TEST  TASK 
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3.2.1.10  Mass  Memory  Test  Task 

The  Mass  Memory  Test  Task  is  activated  during  the  normal  test 
sequence  or  when  a  Mass  Memory  Test  is  specifically  requested  from  the  ground 
crew. 


Computer  requirements  for  the  module  are: 


Memory  Size 

153 

16  bit  words 

Tnroughput 

632 

ms/sec 

Update  Rate 

N/A 

times/sec 

3.2.1.10.1  Inputs 

The  inputs  to  the  Mass  Memory  Test  Task  shall  be  as  specified  in 
Table  XVIII. 

3.2.1.10.2  Processi nq 

The  Mass  Memory  Test  Task  shall  perform  the  processing  specified 
in  Fi gure  1 1 . 

The  Mass  Memory  Test  Task  requests  BIT  data  by  sending  a  Command 
Mode  Message  to  the  Executive  Task.  The  results  are  evaluated  and  used  to 
update  the  status  matrix. 

The  task  shall  next  read  the  first  word  of  every  file  in  Mass 
Memory.  After  signalling  an  event  that  it  would  like  to  read  from  Mass 
Memory,  and  receiving  an  acknowledgement  from  the  Master  Executive,  the  task 
will  write  in  a  compool  the  name  of  the  file  and  the  record  numbers  it  would 
Tike  to  receive.  The  task  will  then  wait  for  an  event  from  the  Master 
Executi ve. 


The  Master  Executive  finds  the  data  on  the  Mass  Memory  and  reads 

/ 

it  into  a  Compool,  32  words  at  a  time.  The  Master  Executive  will  then  signal 
an  event  that  the  data  is  available.  The  Mass  Memory  Test  Task  will  read  the 
data  from  the  Compool  and  signal  that  it  has  been  received. 
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TABLE  XVIII  INPUTS  TO  MASS  MEMORY  TEST  TASK 
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Figure  11  Mass  Memory  Test 
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Figure  11 


Mass  Memory  Test  Task  (Cont.) 


The  task  then  signals  an  event  to  compare  the  first  word  of  a 
file  with  a  stored  word.  If  the  word  is  unacceptable  the  word  will  be  read 
again.  If  it  is  unacceptable,  three  successive  times,  the  recorder  contain¬ 
ing  that  file  will  be  declared  faulty. 

When  all  files  have  been  read  and  all  faults  declared,  the 
status  matrix  will  be  updated  and  displayed  for  the  operator. 

The  task  will  signal  the  Test  Controller  that  the  tests  have 
been  completed. 

3.2.1.10.3  Outputs 

The  outputs  from  the  Mass  Memory  Test  Task  shall  be  as  specified 
in  Table  XIX. 

3.2.2  GTP-2  Program 

The  GTP-2  software  consists  of  a  set  of  test  modules  controlled  by 
the  Test  Master  Sequencer,  the  Test  Request  Processor  and  the  Test  Controller 
with  the  test  results  catalogued  by  the  Subsystem  Status  Monitor  (see  Figure 
12  ).  The  Test  Master  Sequencer  schedules  and  initializes  the  other  two 

system  control  modules. 

The  Test  Request  Processor  interprets  inputs  from  the  IMK.  It  deter¬ 
mines  whether  the  keyboard  inputs  are  test  responses  or  test  sequence  commands. 

The  Test  Controller  is  responsible  for  the  scheduling  of  the  tests  and 
for  activating  the  appropriate  EQUIPS,  DISPs,  and  SPECs  to  perform  the  testing 
function  and  to  display  the  results  on  the  MPD. 

The  EQUIP  modules  will  provide  the  software  interface  between  the 
Remote  Terminals  (RT's)  associated  with  the  individual  avionics  subsystems 
and  the  remainder  of  the  GTP-2  software.  The  EQUIPS  will  process  the  inputs 
from  the  subsystems  to  the  software  and  the  outputs  from  the  GTP-2  to  the 
avionics.  They  will  also  process  any  BITE  data  available  and  will  appropri¬ 
ately  configure  the  status  word  subsequently  used  by  the  Subsystem  Status 
Monitor.  All  the  EQUIPS  used  are  the  same  as  those  in  the  OFP  and  are 
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OUTPUTS  FROM  MASS  MEMORY  TEST  TASK 


Figure  12  GTP-2  Overview 


described  in  the  specification  for  the  OFP-Appl i cation  Software. 


The  DISP  modules  will  cause  the  test  results  advisory  messages,  and 
procedural  instructions  to  be  displayed  on  the  MPD  or  the  IMK.  The  DISP 
modules  to  be  used  are  also  the  same  as  those  in  the  OFP. 

Included  in  the  EQUIP  modules  are  applicable  data  validity  tests  in 
addition  to  the  SITE  data  processing  features.  Any  additional  test  proce¬ 
dures  deemed  necessary  will  be  incorporated  in  the  SPEC  modules. 

Once  the  program  loading  verification  and  initialization  have  been 
completed  by  the  Master  Executive,  the  Test  Master  Sequencer  activates  the 
Test  Controller  which  causes  a  DISP  to  display  a  "Ready-to-Test"  message  on 
the  MPD.  The  normal  subsystem  test  sequence  is  shown  in  Figure  13. 

To  execute  the  entire  GTP-2,  the  operator  need  merely  depress  the 
appropriate  pushbutton  on  the  IMK  and  observe  the  results  of  the  first  test 
on  the  MPD.  The  depression  of  the  IMK  pushbutton  will  cause  the  Test  Request 
Processor  to  activate  the  Test  Controller  which  schedules  the  appropriate 
EQUIPs,  SPECs,  and  DISPs  to  accomplish  the  first  test  sequence.  The  results 
of  the  test  will  be  displayed  on  the  MPD  for  evaluation  by  the  operator,  then 
the  Test  Controller  will  advance  to  the  next  sequential  test  awaiting  the 
command  from  the  Test  Request  Processor  to  begin  execution.  The  next  sequen¬ 
tial  test  may  be  executed  by  the  operator  depressing  the  IMK  pushbutton  again. 
This  procedure  would  be  continued  until  all  of  the  tests  have  been  executed 
and  the  pertinent  test  results,  or  LRU  failure  data,  if  any,  have  been  noted. 

To  initiate  any  specific  test  out  of  the  sequential  order,  the  oper¬ 
ator  must  select  individual  test  option  and  enter  a  two-digit  test  code  (see 
Figure  13  )  into  the  OEK,  then  depress  the  pushbutton  on  the  IMK.  This 

activates  the  Test  Request  Processor  which  then  determines  whether  the  test 
request  is  acceptable  and  whether  the  test  will  interfere  with  another  test, 
i f  any,  in  process. 

This  same  procedure  would  allow  the  operator  to  repeat  a  particular 
test,  or  to  skip  a  test  or  group  of  tests. 
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FIGURE  13  GTP-2  TEST  SEQUENCE 


The  Test  Master  Sequencer  and  the  Test  Request  Processor  described  in 
Sections  3.2.1  and  3.2.2  of  the  GTP-1  will  be  used  during  the  execution  of 
GTP-2. 

3.2.2. 1  Test  Controller  (GTP-2) 

The  Test  Controller  is  activated  to  initiate  testing,  when  there  is 
a  request -for- a  chaage  in  test  sequence  and  after  each  test  is  completed.  It 
is  responsible  for  the  scheduling  of  the  tests.  The  normal  test  sequence  is 
shown  in  Figure 

3.2. 2. 1.1  Inputs 

The  inputs  to  the  Test  Controller  shall  be  as  specified  in  Table 
XX. 

3.2. 2. 1.2  Processing 

Data  initialization  at  start-up  shall  be  signalled  by  the  Start-up 
Flag  Set  in  the  Test  Master  Sequencer.  This  data  initialization  shall  be 
performed  by  setting  the  initialization  flags  in  all  the  modules  requiring 
initialization,  then  scheduling  those  modules.  Any  EQUIPS,  DISPs,  or  SPECs 
associated  with  the  scheduled  test  module  shall  be  scheduled  also  by  the  Test 
Controller. 


The  initialization  of  a  test  sequence  or  a  change  in  one  shall  be 
signalled  by  the  Test  Request  Processor.  Changes  in  the  test  sequence  shall 
be  possible  any  time  unless  the  nature  of  the  test  is  such  that  the  comple¬ 
tion  of  a  previous  test  is  required.  It  sha-1  be  possible  for  any  test  to  be 
scheduled  or  rescheduled  unless  the  scheduling  of  one  test  is  dependent  upon 
the  results  of  a  previous  test.  If  a  test  termination  is  permitted,  the  Test 
Controller  shall  terminate  all  tasks  and  clear  the  displays. 

i 

To  start  the  new  sequence,  the  Test  Controller  shall  signal  the 
appropriate  test  module,  then  shall  activate  a  DISP  to  display  the  test  code 
and  the  name  of  the  test  being  scheduled. 

When  a  test  is  completed,  the  Test  Controller  shall  retain  the 
results  of  the  test  on  the  displays  and  shall  display  the  code  and  name  of 
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the  next  test  to  be  performed.  This  display  shall  be  terminated  by  a  signal 
from  the  Test  Request  Processor  signalling  that  either  the  next,  or  a  new, 
task  is  to  be  scheduled.  The  Test  Processor  shall  then  display  the  new  test 
code  and  name  and  proceed  to  schedule  the  new  test. 

After  the  completion  of  the  last  test,  the  Test  Processor  shall 

cause  the  status  matrix  to  be  displayed  with  a  ‘tests  complete'  statement. 

•  » •  ••  •  .  •  ...  .  . 

The  processing  shall  be  performed  as  is  specified  in  Figure  14. 


3. 2. 2. 1.3  Outputs 

The  outputs  from  the  Test  Controller  shall  be  as  specified  in 
Table  XXI. 

3.2. 2. 2  GTP-2  Test  Modules 

The  GTP-2  Test  Modules,  enumerated  in  Figure  12  are  generally 
complete  in  themselves  and  may  be  executed  individually  or  collectively. 
Exceptions  to  this  rule  are  the  subsystems  tests  for  the  INS  and  the  AHRS. 

The  INS  subsystem  test  comprises  two  separate  tests,  the  INS  Initial 
Check,  which  energizes  the  INS  to  begin  the  self-alignment.  Later  in  the 
test  program,  after  the  INS  has  been  allowed  sufficient  time  to  complete  its 
self-alignment,  the  INS  alignment  Check  program  module  is  executed  to  complete 
the  INS  ground  test.  During  this  test,  the  INS  true  heading  is  compared  with 
the  true  heading  from  the  AHRS.  Consequently,  when  the  INS  is  tested,  it  is 
necessary  to  execute  all  three  program  modules,  i.e.,  the  AHRS  check,  the  INS 
Initial  Check  and  the  INS  Alignment  Check. 

The  GTP-2  test  modules  are  designed  around  the  EQUIP  program  modules 
which  provide  in-flight  8ITE  checks  in  addition  to  their  main  task  as  the 
software  interface  between  the  individual  IDAMST  Avionics  Subsystems  and  the 
IDAMST  Applications  Software. 
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FIGURE  14 


GTP-2  TEST  CONTROLLER 


TABLE  XXI  OUTPUTS  -  GTP-2  TEST  CONTROLLER 


In  addition  to  the  BITE  checks,  the  6TP-2  modules  will  cause  test 
procedures  to  be  displayed  on  the  MPD,  instructing  the  operator  to  manipulate 
certain  controls  and  enter  applicable  data  to  exercise  the  subsystem  under 
test. 


The  results  of  the  individual  tests  will  be  displayed  on  the  MPD 
and,  if  any  out-of- tolerance  results  occur,  the  status  word  will  be  updated 
accordingly. 

For  those  test  modules  involving  calculations  such  as  TACAN,  Multi- 
Mode  Radar,  INS,  etc.,  the  applicable  SPECS  from  the  OFP  will  be  duplicated 
in  the  GTP-2  test  module  to  permit  test  calculations  based  on  simulated 
inputs.  The  results  of  these  calculations  will  be  compared  with  the  pre¬ 
calculated  correct  answers  and  any  deviations  from  the  allowable  tolerance 
will  be  announced  by  a  message  on  the  MPD. 

3.2. 2. 2.1  Intercom  Test 

This  program  module  tests  the  Intercommunication  Set,  AN/AIC-1S. 
This  program  utilizes  the  interface  features  of  the  intercom  EQUIP  program 
module  (OFP  Application).  The  program  instructs  the  operator  to  exercise 

the  control  functions  of  the  Intercom  Set  then  provides  display  outputs  for 
evaluation  by  the  operator. 

3. 2. 2. 2. 1.1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the 
intercom  EQUIP  module. 

3. 2. 2. 2. 1.2  Processing 

This  test  module  shall  call  the  Intercom  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Control/Displays 
and  the  Intercom  Set. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  selector  controls.  It  shall  then  instruct  the  operator  to 
signify  acceptance  or  rejection  of  the  operation  of  the  selector  controls  by 


depressing  an  appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to 
update  the  status  word. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  control  feature  of  the  Intercom  is  tested. 

"  *  AT  the ‘c'o'n elusion  of  the  test,  if  the-  test  results  ore- sa-ti  j- 
factory,  the  test  module  shall  cause  the  display  of  an  appropriate  message 
signifying  the  acceptability  of  the  Intercom.  If  the  results  are  unsatis¬ 
factory,  the  test  module  shall  issue  a  display  list  describing  the  nature  of 
the  failures. 


3. 2. 2. 2. 1 . 3  Outputs 

The  outputs  from  this  program  module  shall  consist  of  the  status 
word,  display  messages,  and  the  test  completion  event. 

3. 2. 2. 2. 2  AHRS  Test 

This  program  module  tests  the  Attitude  and  Heading  Reference 
System  (AHRS),  Lear  Seigler  ?6000A.  This  program  utilizes  the  interface  and 
BITE  features  of  the  AHRS  EQUIP  (  OFP-Appl  I'cation^)  program  module.  It 
ascertains  that  the  AHRS  has  had  sufficient  warm-up,  then  operates  AHRS  in 
both  SLAVE  and  DG  modes.  The  program  instructs  the  operator  to  exercise  the 
various  control  modes,  then  provides  display  outputs  for  evaluation  by  the 
operator.  It  checks  the  outputs  of  pitch,  roll  and  turn  rate  are  reasonable 
values  while  the  aircraft  is  stationary. 

3. 2. 2. 2. 2.1  T " outs 

inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXII . 
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INPUTS  -  AHRS  TEST 


3. 2. 2. 2. 2. 2  Processin 


This  test  module  shall  call  the  AHRS  EQUIP  program  module  which 
shall  effect  a  sufficient  warm-up  time  for  the  AHRS,  shall  provide  the  soft¬ 
ware  interface  between  the  IDAMST  Control/Displays  and  the  AHRS  and  shall 
detect  and  display  the  results  of  the  AHRS  BITE  tests. 

It  shall  determine  if  the  AHRS  outputs  of  pitch  and  roll  are 
reasonable  values  with  the  aircraft  stationary  on  the  ground.  It  shall  cause 
the  results  to  be  displayed  on  the  MPD. 

The  test  module  shall  determine  if  the  A  RS  outputs  of  turn  rate 
and  roll  rate  are  zero  with  the  aircraft  stationary  on  the  ground.  It  shall 
cause  the  results  to  be  displayed  on  the  MPD. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  change  the  mode  to  "DG",  then  to  exercise  the  heading  slew  control  in  both 
directions.  The  operator  shall  be  instructed  to  change  the  mode  back  to 
"SLAVE",  then  to  observe  that  the  resulting  heading  output  is  reasonable. 

The  test  module  shall  instruct  the  operator  to  signify  acceptance  or  rejec¬ 
tion  of  the  heading  output  by  depressing  an  appropriate  button  on  the  DEK. 
This  rejection  shall  be  used  to  update  the  status  word. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  "SYNCH"  feature  including  the  display  of  the  results  to  the 
operator. 


The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  "HEMISPHERE  SELECT"  and  “FAST  ERECTION  COMMAND"  features 
including  the  display  of  the  results  to  the  operator. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  feature  of  the  AHRS  is  tested. 

At  the  conclusion  of  the  AHRS  test,  if  the  results  are  satis¬ 
factory,  the  test  module  shall  cause  a  display  of  an  appropriate  message 
signifying  the  acceptability  of  the  AHRS.  If  the  results  are  unsatisfactory, 
the  test  module  shall  cause  the  display  of  a  message  signifying  the 


unacceptabi 1 i ty  of  the  AHRS  and  a  display  list  describing  the  nature  of  the 
failures. 


The  processing  shall  be  performed  as  is  specified  in  Figure  15. 


3. 2. 2. 2. 2. 3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 
Table  XXIII. 

3. 2. 2. 2. 3  Initial  INS  Test 

This  program  module  energizes  the  Inertial  Navigation  System  (INS) 
to  initiate  the  alignment  process  prior  to  the  INS  Alignment  Test  (see 
Section  3.2.2.2.22).  The  program  instructs  the  operator  to  set  the  proper 
controls  then  provides  display  outputs  for  evaluation  by  the  operator.  This 
program  utilizes  the  interface  features  of  the  INS  EQUIP  program  module 
(OFP-Appl ications) . 

3. 2. 2. 2. 3.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXIV. 

3. 2. 2. 2. 3. 2  Processi nq 

This  test  module  shall  call  the  INS  EQUIP  program  module  which 
shall  provide  the  software  int  rface  between  the  IDAMST  Control /Displ ays  and 
the  INS  and  shall  detect  and  display  the  INS  BITE  tests. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  properly  control  the  INS  to  initiate  the  INS  Alignment. 

The  processing  shall  be  performed  as  specified  in  Figure  16. 


FIGURE  15 
AHRS  TEST 
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FIGURE  15  (Cont.) 


OUTPUTS  -  AHRS  TEST 


3. 2. 2. 2. 3. 3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXV. 


3. 2. 2. 2. 4  Public  Address  System  Test 

This  program  module  tests  the  Public  Address  System,  AN/AIC-13. 

It  utilizes  the  interface  features  of  the  Public  Address  EQUIP  Program 
module.  The  program  instructs  the  operator  to  exercise  the  control  selectors 
then  provides  display  outputs  for  evaluation  by  the  operator. 

3. 2. 2. 2. 4.1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the 
Public  Address  EQUIP  module. 

3. 2. 2. 2. 4. 2  Processing 

This  test  module  shall  call  the  Public  Address  EQUIP  program 
module  which  shall  provide  the  software  interface  between  the  IDAMST  Control/ 
Displays  and  the  Public  Address  System. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  control  selector  options.  It  shall  then  instruct  him  to 
signify  acceptance  or  rejection  of  the  results  by  depressing  an  appropriate 
button  on  the  DEK.  This  rejection  shall  be  used  to  update  the  status  word. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  control  feature  of  the  Public  Address  System  is 
tested. 


At  the  conclusion  of  the  tests,  if  the  results  are  satisfactory, 
the  test  module  shall  display  an  appropriate  message  signifying  the  accept¬ 
ability  of  the  Public  Address  System.  If  the  test  results  are  unsatisfactory, 
the  test  module  shall  issue  a  display  list  describing  the  nature  of  the 
fai lures. 
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3. 2. 2. 2. 4. 3  Outputs 

The  outputs  from  this  test  module  shall  consist  of  the  status 
word,  display  messages,  and  test  completion  event. 

3. 2. 2. 2. 5  Speech  Security  Set  Test 

This  program  module  tests  the  Speech  Security  Set,  TSEC/KY-53. 

It  utilizes  the  interface  features  of  the  Speech  Security  Set  EQUIP  program 
module  ( OFP-Appl ication) .  The  program  instructs  the  operator  to  exercise 
the  control  and  mode  selectors,  then  provides  display  outputs  for  evaluation 
by  the  operator. 

3. 2. 2. 2. 5.1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the  Speech 
Security  Set  EQUIP  module. 

3. 2. 2. 2. 5. 2  Processing 

This  test  module  shall  call  the  Speech  Security  Set  EQUIP  which 
shall  provide  the  software  interface  between  the  IDAMST  Control/Displays  and 
the  Speech  Security  Set. 

The  test  module  shall  display  instructions  to  the  operator  to 
exercise  the  control  and  mode  selectors.  It  shall  then  instruct  the  operator 
to  observe  and  evaluate  the  resulting  response  then  signify  acceptance  or 
rejection  of  the  operation  of  the  control  of  mode  selectors  by  depressing  an 
appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to  update  the 
status  word. 


The  test  module  shall  display  the  appropriate  failure  messages 
after  each  separate  control  feature  of  the  Speech  Security  Set  is  tested. 

At  the  conclusion  of  the  test,  if  the  results  are  satisfactory, 
the  test  module  shall  display  an  appropriate  message  signifying  the  accepta¬ 
bility  of  the  Speech  Security  Set.  If  the  test  results  are  unsatisfactory, 
tne  test  module  shall  issue  a  display  list  describing  the  nature  of  the 
fa i 1 ures . 
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3. 2. 2. 2. 5. 3  Outputs 


The  outputs  from  this  test  module  shall  consist  of  the  status 
/wrd,  display  messages,  and  test  completion  event. 

3. 2. 2. 2. 6  UHF  £1  Test 

This  program  module  tests  the  UHF  Radio  Transceiver,  AN/ARC-164. 
This  program  utilizes  the  interface  features  of  the  UHF  EQUIP  program  module 
(  OFP-Appl ication) .  The  program  instructs  the  operator  to  exercise  the 
control  and  frequency  selection  functions,  then  provides  display  outputs  for 
evaluation  by  the  operator. 

3. 2. 2.  2. 5.1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the 
JHF  EQUIP  module. 

3. 2. 2. 2. 6. 2  Process! ng 

This  test  module  shall  call  the  UHF  EQUIP  program  module  which 
shall  provide  the  software  interface  between  the  IDAMST  Control/Displays  and 
the  UHF  Transcei ver. 

The  test  module  shall  display  instructions  to  the  operator  to 
exercise  the  control  and  frequency  selectors.  It  shall  instruct  the  operator 
to  observe  and  evaluate  the  resulting  response,  then  signify  acceptance  or 
rejection  of  the  operation  of  the  control  and  frequency  selectors  by  depres¬ 
sing  an  appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to 
update  the  status  word. 

The  test  module  shall  display  the  appropriate  failure  messages 
after  each  separate  control  feature  of  the  UHF  Transceiver  is  tested. 
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At  the  conclusion  of  the  test,  if  the  results  are  satisfactory, 
the  test  module  shall  display  an  appropriate  message  signifying  the  accept¬ 
ability  of  the  UHF  Transceiver.  If  the  test  results  are  unsatisfactory,  the 
test  module  shall  issue  a  display  list  describing  the  nature  of  the  failure. 


3. 2 . 2. 2.6. 3  Outputs 

The  outputs  from  this  test  module  shall  consist  of  the  status 
word,  display  messages,  and  test  completion  event. 

3. 2. 2. 2. 7  UHF  ^2  Test 

This  program  module  is  identical  to  that  module  described  in 
paragraph  3. 2. 2. 2. 6  except  for  the  address  of  the  'JHF  EQUIP  called  by  the 
test  program  module. 

3. 2. 2. 2. 3  VHF/AM  Transceiver  Test 

This  program  module  tests  the  VHF/AM  Transceiver  Set.  AN/ ARC - 11 5R . 
This  program  utilizes  the  interface  features  of  the  VHF/AM  EQUIP  program 
module  (See  OF P  Application).  The  program  instructs  the  operator  to 

exercise  the  mode  control  and  frequency  select  functions  of  the  VHF/AM  Set 
then  provides  display  outputs  for  evaluation  by  the  operator. 

3. 2. 2. 2. 8.1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the 
VHF/AM  EQUIP  module. 

3. 2. 2. 2. 8. 2  Processi nq 

This  test  module  shall  call  the  VHF/AM  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Contro I /Di spl ays 
and  the  VHF/AM  Set. 
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The  test  module  shall  display  instructions  to  the  operator  to 
exercise  the  mode  control  and  frequency  selectors.  It  shall  instruct  the 
operator  to  observe  and  evaluate  the  resulting  response,  then  signify  accept¬ 
ance  or  rejection  of  the  operation  of  the  mode  control  and  frequency  selectors 
by  depressing  an  appropriate  button  on  the  DEK.  This  rejection  shall  be  used 
to  update  the  status  word. 

The  test  module  shall  display  the  appropriate  failure  messages 
after  each  separate  control  feature  of  the  VHF/AM  Set  is  tested. 

At  the  conclusion  of  the  test,  if  the  results  are  satisfactory, 
the  test  module  shall  display  an  appropriate  message  signifying  the  accept¬ 
ability  of  the  VHF/AM  Transceiver.  If  the  test  results  are  unsatisfactory, 
the  test  module  shall  issue  a  display  list  describing  the  nature  of  the 
fai 1 ure. 


3. 2. 2. 2. 8. 3  Outputs 

The  outputs  from  this  test  module  shall  consist  of  the  status 
word,  display  messages,  and  test  completion  event. 

3. 2. 2. 2. 9  VHF/FM  Transceiver  Test 

This  program  module  tests  the  VHF/FM  Transceiver,  FM-622A.  This 
program  utilizes  the  interface  features  of  the  VHF/FM  EQUIP  program  module 
(OFP-Appl ication) .  The  program  instructs  the  operator  to  exercise  the 

mode  control  and  frequency  selector  functions,  then  provides  display  outputs 
for  evaluation  by  the  operator. 

3 . 2 . 2. 2 . 9 . 1  Inputs 

The  inputs  to  this  test  module  shall  be  the  outputs  of  the 
. FM  EQUIP  module. 


3. 2. 2. 2.9. 2  Processing 


This  test  module  shall  call  the  VHF/FM  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Control/Displays 
and  the  VHF/FM  Set. 

The  test  module  shall  display  instructions  to  the  operator  to 
exercise  the  control  and  frequency  selectors.  It  shall  instruct  the  operator 
to  observe  and  evaluate  the  resulting  response,  then  signify  acceptance  or 
rejection  of  the  operation  of  the  control  and  frequency  selectors  by  depress¬ 
ing  an  appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to  update 
the  status  word. 

The  test  module  shall  display  the  appropriate  failure  messages 
after  each  separate  control  feature  of  the  VHF/FM  Set  is  used. 

At  the  conclusion  of  the  test,  if  the  results  are  satisfactory, 
the  test  module  shall  display  an  appropriate  message  signifying  the  accept¬ 
ability  of  the  VHF/FM  Transceiver.  If  the  results  are  unsatisfactory ,  the 
test  module  shall  issue  a  display  list  describing  the  nature  of  the  failure. 


3. 2. 2. 2. 9. 3  Outputs 

The  outputs  from  this  test  module  shall  consist  of  the  status 
word,  display  messages,  and  test  completion  event. 

3.2.2.2.10  TACAN  Test 

This  program  module  tests  the  TACAN  Receiver/Transmitter, 
AN/ARN-113.  This  program  utilizes  the  interface  and  BITE  features  of  the 
TACAN'  EQUIP  program  module.  It  ascertains  that  the  TACAN  has  had  sufficient 
warm-up  time,  then  operates  the  TACAN  in  all  three  modes,  "REC,"  “A/A  REC," 
and  11  A/A  T/R."  The  program  instructs  the  operator  to  exercise  the  various 
controls,  then  provides  display  outputs  for  evaluation  by  the  operator.  It 
will  execute  navigational  fix  computations  in  the  three  modes  based  on  simu¬ 
lated  TACAN  inputs  and  will  provide  display  data  of  the  results  for  evaluation 
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by  the  operator. 


3.2.2.2.10.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXVI. 

3.2.2.2.10.2  Processing 

This  test  module  shall  call  the  TACAN  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Control/Displays 
and  the  TACAN  Receiver/Transmitter  and  shall  detect  and  display  the  TACAN  BI'iE 
tests. 

The  test  module  shall  provide  inputs  to  simulate  the  TACAN 
slant  range  and  bearing  signals  for  the  purpose  of  determining  the  naviga¬ 
tional  fix  computation  capability  of  the  TACAN  Receiver  Section.  The  test 
module  snail  use  the  Nav  Brute  Force  SPEC  for  this  computation.  The  program 
shall  provide  for  navigational  fix  problems  in  each  of  the  three  TACAN  modes 
of  operation. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  control  features  of  the  TACAN  Receiver/Transmitter.  It  shall 
then  instruct  the  operator  to  signify  acceptance  or  rejection  of  the  operation 
of  each  control  feature  by  depressing  an  appropriate  button  on  the  DEK. 

This  rejection  shall  be  used  to  update  the  status  word. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  control  feature  of  the  TACAN  Receiver/Transmitter 
is  tested. 

The  processing  shall  be  performed  as  is  specified  in  Figure  17  • 


3.2.2.2.10.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXVII. 
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TACAN  TEST 


TACAN  TEST 


OUTPUTS  -  TACAN  TEST 


3.2.2.2.11  Instrument  Landing  System  (ILS)  #1  Test 

This  program  module  tests  the  Instrument  Landing  System  (ILS) 
Receiver,  AfVARN-108.  This  program  utilizes  the  interface  and  BITE  features 
of  the  ILS  EQUIP  program  module  (see  OFP-Appl ication) .  The  program  instruct 
the  operator  to  exercise  the  control  and  frequency  selection  functions,  then 
provides  display  outputs  for  evaluation  by  the  operator. 


3.2.2.2.11 .1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table 

3.2.2.2.11.2  Process i nq 

This  test  module  shall  call  the  ILS  EQUIP  program  module  which 
shall  provide  the  software  interface  between  the  IDAMST  Control/Displays  and 
the  ILS  Receiver  and  shall  detect  and  display  the  results  of  the  ILS  BITE 
tests. 


The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  frequency  selector  control.  It  shall  then  instruct  the  oper¬ 
ator  to  signify  acceptance  or  rejection  of  the  operation  of  the  frequency 
selector  by  depressing  an  appropriate  button  on  the  DEK.  This  rejection 
shall  be  used  to  update  the  status  word. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  control  feature  of  the  ILS  Receiver  is  tested. 

At  the  conclusion  of  the  ILS  test,  if  the  test  results  are 
satisfactory,  the  test  module  shall  cause  the  display  of  an  appropriate 
message  signifying  the  acceptability  of  the  ILS  Receiver.  If  the  test 
results  are  unsatisfactory,  the  test  module  shall  issue  a  display  list 
describing  the  nature  of  the  failures. 

The  processing  shall  be  performed  as  is  specified  in  Figure  IS. 
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ILS  TEST 


36 


3.2.2.2.11.3  Outputs 


The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXIX. 

3.2.2.2.12  Instrument  Landing  System  (ILS)  #2  Test 

This  program  module  is  identical  with  that  described  in  paragraph 
3.2.2.2.11  except  for  the  address  of  the  ILS  EQUIP  called  by  the  test  program 
module. 

3.2.2.2.13  LF/ADF  Receiver  Test 

This  program  module  tests  the  LF/ADF  Receiver,  Collins  -DF-206. 
This  program  utilizes  the  interface  and  BITE  features  of  tne  LF/ADF  EQUIP 
program  module  (see  0F°-Appl  i cation)  .  The  program  instructs  the  operator 
to  exercise  the  control  and  frequency  functions,  then  provides  display  outputs 
for  evaluation  by  the  operator.  The  program  additionally  instructs  the  oper¬ 
ator  to  initiate  the  self-test  mode,  then  provides  display  outputs  for 
evaluation. 

3.2.2.2.13.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXX. 

3.2.2.2.13.2  Processing 

This  test  module  shall  call  the  LF/ADF  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Control/Displays 
and  the  LF/ADF  Receiver  and  shall  detect  and  display  the  results  of  the 
LF/ADF  BITE  tests. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  the  frequency  selector,  the  mode  control  and  the  self-test 
feature.  It  shall  then  instruct  the  operator  to  signify  acceptance  or 
rejection  of  the  operation  by  depressing  an  appropriate  button  on  the  DEK. 

This  rejection  shall  be  used  to  update  the  status  word. 
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LF/ADF  TEST 


The  test  module  shall  cause  the  display  of  an  appropriate  fail 
ure  after  each  separate  control  feature  of  the  LF/ADF  Receiver  is  tested. 

At  the  conclusion  of  the  LF/ADF  test,  if  the  test  results  are 
satisfactory,  the  test  module  shall  cause  the  display  of  an  appropriate 
message  signifying  the  acceptability  of  the  LF/ADF.  If  the  results  are 
unsatisfactory,  the  test  module  shall  issue  a  display  list  describing  the 
nature  of  the  fai 1 ure. 

The  processing  shall  be  performed  as  is  specified  in  Figure  19 

3.2.2.2.13.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXXI. 

3.2.2.2.14  Mul ti -Mode  Radar  Test 

This  program  module  tests  the  Multi -Mode  Radar  Set,  AN/APQ- 
1 22 ( V ) 5 .  This  program  utilizes  the  interface  and  BITE  features  of  the  Multi 
Mode  Radar  EQUIP  program  module  (see  nFp-App1 icaticn) .  The  program 
instructs  the  operator  to  exercise  tne  various  control  modes,  then  provides 
display  outputs  for  evaluation  by  the  operator.  It  will  also  execute  a 
navigational  fix  computation  based  on  inputs  inserted  by  the  operator  via 
the  Hand  Control  Uni l. 

3.2.2.2.14.1  Inputs 

The  input'  to  tnis  program  module  shall  be  as  specified  in 

Table  XXXII. 

3.2.2.2.14.2  Processing 

This  test  module  shall  call  the  MMRAD  EQL'IP  program  module 
which  snail  provide  the  software  interface  between  the  1DAMST  Control/Displa 
and  the  Multi-Mode  Radar  Set  and  shall  detect  ard  '-'splay  the  results  of  the 
Multi -Mode  Radar  BITE  tests. 
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The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  the  operational  modes.  It  shall  then  instruct  the  operator 
to  signify  acceptance  or  rejection  of  each  operational  mode  by  depressing  an 
appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to  update  the 
status  word. 


The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  feature  of  the  Radar  Set  is  tested. 

The  test  module  shall  instruct  the  operator  to  exercise  the 
Hand  Control  Unit  (HCU)  to  ascertain  its  proper  functioning.  It  shall  then 
instruct  the  operator  to  position  the  cursor  with  the  HCU  on  a  particular 
range  and  bearing  position  for  the  purpose  of  determining  the  navigational 
fix  computation  capability  of  the  Radar  Set.  The  test  module  shall  use  the 
Nav  Brute  Force  SPEC  for  this  computation. 

The  processing  shall  be  performed  as  is  specified  in  Figure  20. 


3.2.2.2.14.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXXIII. 

3.2.2.2.15  Radar  Altimeter  #1  Test 

This  program  module  tests  the  Radar  Altimeter  System,  AN/APN-194. 
This  program  utilizes  the  interface  and  BITE  features  of  the  Radar  Altimeter 
EQUIP  program  module  (see  OFP-Application).  It  provides  sufficient 

warm-up  time,  then  operates  the  Radar  Altimeter  in  the  test  mode.  The  program 
instructs  the  operator  to  initiate  the  self-test  mode  and  provides  display 
outputs  for  evaluation  by  the  operator. 

/ 

3.2.2.2.15.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXXIV. 
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FIGURE  20 

MULTI -MODE  RADAR  TEST 
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MULTI -MODE  RADAR  TEST 
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TABLE  XXXIII  OUTPUTS  -  MULTI-MODE  RADAR  TEST 


TABLE  XXXIV  INPUTS  -  RADAR  ALTIMETER  TEST 


3.2.2.2.15.2  Processing 


This  test  module  shall  call  the  RADALT  EQUIP  program  module 
which  shall  effect  a  sufficient  warm-up  time  for  the  Radar  Altimeter,  shall 
provide  the  software  interface  between  the  IDAMST  Control /Displays  and  the 
Radar  Altimeter  and  shall  detect  and  display  the  results  of  the  Radar  Altim¬ 
eter  BITE  tests. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  initiate  the  Radar  Altimeter  Self-Test  mode. 

At  the  conclusion  of  the  Radar  Altimeter  Test,  if  the  results 
are  satisfactory,  the  test  module  shall  cause  the  display  of  an  appropriate 
message  signifying  the  acceptability  of  the  Radar  Altimeter.  If  the  results 
are  unsatisfactory,  the  test  module  shall  cause  the  display  of  a  message 
signifying  the  unacceptability  of  the  Radar  Altimeter  and  a  display  list 
describing  the  nature  of  the  failures. 

The  processing  shall  be  performed  as  is  specified  in  Figure 


3.2.2.2.15.3  Outputs 

The  outputs  from  the  test  module  shall  be  as  specified  in 

Table  XXXV. 


3.2.2.2.16  Radar  Altimeter  #2  Test 

This  program  module  is  identical  with  that  described  in  3.2.2.2.15 
except  for  the  address  of  the  Radar  Altimeter  EQUIP  called  by  the  test  program 
module. 

3.2.2.2.17  Radar  Beacon  Test 

t 

This  program  module  tests  the  Transponder  Set  (Radar  Beacon), 
AN/UPN-25.  This  program  utilizes  the  interface  features  of  the  Radar  Beacon 
Transponder  EQUIP  program  module.  The  program  instructs  the  operator  to 
select  the  mode  of  operation  of  the  Radar  Beacon  in  conjunction  with  the 
AN/UPM-138  Confidence  Test  Set,  then  provides  display  outputs  for  evaluation 
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FIGURE  21 


RADAR  ALTIMETER  TEST 
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OUTPUTS  -  RADAR  ALTIMETER  TEST 


by  the  operator. 


3.2.2.2.17.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XXXVI. 

3.2.2.2.17.2  Processing 

This  test  module  shall  call  the  Radar  Beacon  EQUIP  program 
module  which  shall  provide  the  software  interface  between  the  IDAMST  Control/ 
Displays  and  the  Radar  Beacon  Receiver. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  employ  the  Radar  Beacon  Confidence  Test  Set,  AN/UPM-138,  to  operate  in 
conjunction  with  the  Radar  Beacon.  It  shall  then  instruct  the  operator  to 
change  operating  modes  and  to  signify  the  acceptance  or  rejection  of  the 
results  by  depressing  an  appropriate  button  on  the  DEK.  This  rejection  shall 
be  used  to  update  the  status  word. 

The  test  module  shall  cause  the  display  of  an  appropriate  fail¬ 
ure  message  after  each  separate  control  feature  of  the  Radar  Beacon  is  tested. 

At  the  conclusion  of  the  Radar  Beacon  Test,  if  the  test  results 
are  satisfactory,  the  test  module  shall  cause  the  display  of  an  appropriate 
message  signifying  the  acceptability  of  the  Radar  Beacon.  If  the  results  are 
unsatisfactory,  the  test  module  shall  issue  a  display  list  describing  the 
nature  of  the  failure. 

The  processing  shall  be  performed  as  specified  in  Figure  22. 


3.2.2.2.17.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXXVII. 
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TABLE  XXXVI  INPUTS  -  RADAR  BEACON  TEST 


FIGURE  22 
RADAR  BEACON  TEST 
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RADAR  BEACON  TEST 
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3.2.2.2.18  Station  Keeping  Equipment  (SKE)  Test 

This  program  module  tests  the  Station  Keeping  Equipment  (SKE), 
AN/APN-169B.  This  program  utilizes  the  interface  and  BITE  features  of  the 
SKE  EQUIP  program  module  (see  OFP-Aoolication  ).  The  program  instructs 
the  operator  to  exercise  the  various  control  and  test  modes,  then  provides 
display  outputs  for  evaluation  by  the  operator.  It  will  also  execute  a 
navigational  fix  computation  based  on  simulated  zone  marker  inputs. 

3.2.2.2.18.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 
Table  XXXVIII. 

3.2.2.2.18.2  Processing 

This  test  module  shall  call  the  SKE  EQUIP  program  module  which 
shall  provide  the  software  interface  between  the  IDAMST  Control/Displays  and 
the  SKE  and  shall  detect  and  display  the  results  of  the  SKE  BITE. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  the  operational  modes.  It  shall  then  instruct  the  operator 
to  signify  acceptance  or  rejection  of  each  operational  mode  by  depressing  an 
appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to  update  the 
status  word. 


The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  feature  of  the  SKE  is  tested. 

To  test  the  navigational  fix  computation  capability  of  the  SKE 
when  used  in  conjunction  with  a  zone  marker  (ZM),  the  test  module  shall 
introduce  values  of  slant  range  and  relative  bearing  to  simulate  the  zone 
marker  imputs.  The  test  module  shall  use  the  Nav  Brute  Force  SPEC  for  this 
computation. 


The  processing  shall  be  performed  as  is  specified  in  Figure  23. 
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TABLE  XXXVIII  INPUTS  -  STATION  KEEPING  EQUIPMENT  (SKE)  TEST 


FIGURE  23 

STATION  KEEPING  EQUIPMENT  (SKE)  TEST 
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MPD  DISP 


FIGURE  23  (Cont.) 

STATION  KEEPING  EQUIPMENT  (SKE)  TEST 
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3.2.2.2.18.3  Outputs 


The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XXXIX. 

3.2.2.2.19  OMEGA  Test 

This  program  module  tests  the  OMEGA  Navigational  Equipment.  This 
program  utilizes  the  interface  and  BITE  features  of  the  OMEGA  EQUIP  program 
module.  The  program  instructs  the  operator  to  insert  the  proper  initializa¬ 
tion  data.  It  will  execute  a  navigational  fix  computation  based  on  simulated 
OMEGA  inputs  and  will  provide  display  data  of  the  results  for  evaluation  by 
the  operator.  It  will  also  provide  simulated  inputs  to  the  OMEGA  to  test  the 
dead  reckoning  capability  of  the  OMEGA,  then  will  display  data  of  the  results 
for  evaluation  by  the  operator. 

3.2.2.2.19.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XL. 


3.2.2.2.19.2  Processing 

This  test  module  shall  call  the  OMEGA  EQUIP  program  module 
which  shall  provide  the  software  interface  between  the  IDAMST  Control /Displays 
and  the  OMEGA  and  shall  detect  and  display  the  OMEGA  BITE  tests. 

The  test  module  shall  provide  inputs  to  simulate  the  OMEGA 
signals  for  the  purpose  of  determining  the  navigation  fix  computation  capa¬ 
bility  of  the  OMEGA  receiver.  The  test  module  shall  use  the  Nav  Brute  Force 
SPEC  for  this  computation. 

The  test  module  shall  provide  inputs  to  simulate  true  airspeed, 
wind  direction  and  velocity  and  compass  heading  for  the  purpose  of  determining 
the  dead  reckoning  capability  of  the  OMEGA  computer.  The  test  module  shall 
also  use  the  Nav  Brute  Force  SPEC  for  this  computation. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  control  features  of  the  OMEGA.  It  shall  then  instruct  the 
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TABLE  XXXIX  OUTPUTS  -  STATION  KEEPING  EQUIPMENT  (SKE)  TEST 


TABLE  XL  INPUTS  -  OMEGA  TEST 


operator  to  signify  acceptance  or  rejection  of  each  control  feature  by 
depressing  an  appropriate  button  on  the  DEK.  This  rejection  shall  be  used 
to  update  the  status  word. 


The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  control  feature  of  the  OMEGA  is  tested. 

The  processing  shall  be  performed  as  is  specified  in  Figure  24. 


3.2.2.2.19.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XLI. 


3.2.2.2.20  INS  Alignment  Test 

This  program  module  tests  the  final  alignment  of  the  Carousel  IV 
Inertial  Navigation  System.  This  module  completes  the  testing  of  the  INS 
after  the  initialization  begun  in  the  Initial  INS  Test  (see  paragraph 
3. 2. 2. 2. 3).  This  program  instructs  the  operator  to  exercise  the  various  con¬ 
trols  and  modes  of  operation,  then  provides  display  outputs  for  evaluation  by 
the  operator.  It  will  execute  navigational  fix  computations  based  on  simu¬ 
lated  inputs  and  will  provide  display  data  of  the  results  for  evaluation  by 
the  operator.  It  will  check  that  the  outputs  of  pitch  and  roll  are  reason¬ 
able  values  while  the  aircraft  is  stationary.  This  program  utilizes  the 
interface  and  BITE  features  of  the  INS  EQUIP  program  module  (OFP-Appl ication) . 

3.2.2.2.20.1  Inputs 

The  inputs  to  this  program  module  shall  be  as  specified  in 

Table;  XLII. 

3.2.2.2.20.2  Processing 

This  test  module  shall  call  the  INS  EQUIP  program  module  which 
shall  provide  the  software  ir^erface  between  the  IDAMST  Control /Displays  and 
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Figure  24 


OMEGA  Test 


TABLE  XLI  OUTPUTS  -  OMEGA  TEST 
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TABLE  XLII  INPUTS  -  INS  ALIGNMENT  TEST 


the  INS  and  shall  detect  and  display  the  INS  BITE  tests. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  the  control  features  and  modes  of  the  INS.  It  shall  then 
instruct  the  operator  to  signify  acceptance  or  rejection  of  the  operation  of 
each  control  feature  by  depressing  an  appropriate  button  on  the  DEK.  This 
rejection  shall  be  used  to  update  the  status  word. 

The  test  module  shall  instruct  the  operator  to  initiate  the 
test  feature,  then  shall  display  an  appropriate  message  describing  the 
results  of  the  testing. 

The  test  module  shall  determine  if  the  INS  outputs  of  pitch 
and  roll  are  reasonable  values  with  the  aircraft  stationary  on  the  ground. 

It  shall  cause  the  results  to  be  displayed  on  the  MPD.  At  the  conclusion  of 
the  INS  Alignment  Test,  if  the  results  are  satisfactory,  the  test  module 
shall  cause  a  display  of  an  appropriate  message  signifying  the  acceptability 
of  the  INS.  If  the  results  are  unsatisfactory,  the  test  module  shall  cause 
the  display  of  a  message  signifying  the  unacceptability  of  the  INS  and  a 
display  list  describing  the  nature  of  the  failures. 

The  processing  shall  be  performed  as  specified  in  Figure  25. 


3.2.2.2.20.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 

Table  XLIn. 

3.2.2.2.21  IFF  Transponder  Test 

This  program  module  tests  the  IFF  Transponder,  AN/APX-101.  This 
program  utilizes  the  interface  ard  BITE  features  of  the  IFF  EQUIP  program 
module  (see  OFP-Appl ication) .  The  program  instructs  the  operator  to 

exercise  the  various  control  and  test  modes,  then  provides  display  outputs 
for  evaluation  by  the  operator. 
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FIGURE  25  INS  ALIGNMENT  TEST 
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TABLE  XL III  OUTPUTS  -  INS  ALIGNMENT  TEST 


3.2.2.2.21.1  Inputs 


The  inputs  to  this  program  module  shall  be  as  specified  in 

Table  XLIV. 

3.2.2.2.21.2  Processing 

This  test  module  shall  call  the  IFF  EQUIP  program  module  which 
shall  provide  the  software  interface  between  the  IDAMST  Control /Display  and 
the  IFF  Transponder  and  shall  detect  and  display  the  results  of  the  IFF 
Transponder  BITE  tests. 

The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  exercise  all  the  operational  moces.  It  shall  then  instruct  the  operator 
to  signify  acceptance  or  rejection  of  each  operational  mode  by  depressing  an 
appropriate  button  on  the  DEK.  This  rejection  shall  be  used  to  update  the 
status  word. 


The  test  module  shall  cause  a  display  to  instruct  the  operator 
to  activate  all  the  mode  test  options,  then  shall  instruct  the  operator  to 
signify  acceptance  or  rejection  of  the  results  by  depressing  an  appropriate 
botton  on  the  DEK.  This  rejection  shall  be  used  to  update  the  status  word. 

The  test  module  shall  cause  the  display  of  appropriate  failure 
messages  after  each  separate  feature  of  the  IFF  Transponder  is  tested. 

At  the  conclusion  of  the  IFF  Transponder  test,  if  the  results 
are  all  satisfactory,  the  test  module  shall  cause  the  display  of  an  appropriate 
message  signifying  the  acceptability  of  the  IFF  Transponder.  If  the  results 
are  not  all  satisfactory,  the  test  module  shall  cause  the  display  of  a  message 
stating  the  unacceptability  of  the  IFF  Transponder  and  a  display  list 
describing  the  nature  of  the  failure. 

/ 

The  processing  shall  be  performed  as  is  specified  in  Figure  26. 


3.2.2.2.21.3  Outputs 

The  outputs  from  this  test  module  shall  be  as  specified  in 


Table  XLV. 
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TABLE  XL IV  INPUTS  -  IFF  TRANSPONDER  TEST 


FIGURE  26  IFF  TRANSPONDER  TEST 


TABLE  XLV  OUTPUTS  -  IFF  TRANSPONDER  TEST 


4.0  QUALITY  ASSURANCE  PROVISIONS 
4.1  Introduction 

Tests  and  evaluations  shall  be  conducted  to  verify  that  the  performance 
and  design  of  the  0TP(GTP-1 ,GTP-2) shall  meet  or  exceed  the  requirements 
specified  in  Section  3.0.  The  test  category,  verification  method,  and  test 
requirements  for  performance/design  requirements  are  specified  in  the  Verifi¬ 
cation  Cross-Reference  Index  (VCRI),  Table  XLVI. 

The  requirements  delineated  shall  be  the  basis  for  the  test  plan  and 
test  procedure  which  shall  be  written.  The  four  methods  given  in  Table  XLVI 
of  verifying  individual  requirements  are  explained  as  follows: 

a.  Inspection  -  Formal  verification  of  a  performance  of  a  design 
requirement  by  examination  of  the  assembled  CPCI  at  the  time  and  place  of 
qualification  testing.  Inspection  is  not  often  specified  as  a  formal  means 
of  verification  for  a  requirement.  One  set  of  requirements  that  might  be 
verified  by  inspection  are  the  data  base  requirements,  which  can  be  verified 
by  comparing  the  data  base  documentation  with  a  system  tape  listing. 

b.  Analysis  -  Formal  verification  of  a  performance  or  design  require¬ 
ment  by  examination  of  the  constituent  elements  of  a  CPCI  component.  For 
example,  a  weapons  guidance  equation  or  a  coordinate  conversion  equation 
might  be  verified  by  analysis. 

c.  Demonstration  -  Formal  verification  of  a  performance  or  design 
requirement  by  observation  of  a  demonstration  test.  For  example,  visual 
demonstration  might  be  used  to  verify  that  the  displays  generated  by  the  CPCI 
are  in  the  fprmat  necessary  to  satisfy  human  performance  requirements. 

d.  Review  of  Test  Data  -  Formal  verification  of  a  performance  or 

design  requirement  by  examining  the  data  output  after  operation  of  a  CPCI 

/ 

component  when  selected  input  data  are  processed.  For  example,  a  review  of 
hardcopy  printout  test  data  might  be  used  to  verify  that  the  content  of  a 
specific  told-in  message  is  correctly  processed.  This  method  is  the  one 
likely  to  be  used  for  the  majority  of  qualification  testing. 


Narrative  data  pertaining  to  test  categories,  amplifying  the  tabular 
content  of  the  VCRI  are  specified  in  subparagraphs  below.  Test  requirements 
referenced  in  the  VCRI  are  specified  in  paragraph  4.2  and  subparagraphs 
thereto. 

4.1.1  Category  I  Test 

Category  I  testing  is  subdivided  into  the  following  broad  types: 

a.  Computer  program  test  and  evaluation  -  Tests  conducted  prior  to 
and  in  parallel  with  preliminary  or  formal  qualification  tests.  These  tests 
are  oriented  primarily  to  support  the  design  and  development  process. 

b.  Preliminary  qualification  tests  -  Formal  tests  oriented  primarily 
towards  verifying  portions  of  the  CPC  I  prior  to  integrated  testing/formal 
qualification  tests  of  the  complete  CPCI  (see  paragraph  4.1.3  below).  These 
tests  will  typically  be  conducted  at  the  contractor's  design  and  development 
facilities. 


c.  Formal  qualification  tests  -  Formal  tests  oriented  primarily 
towards  testing  of  the  integrated  CPCI,  normally  using  operationally  con¬ 
figured  equipment  at  the  Category  II  site  prior  to  the  beginning  of  Category 
II  testing.  This  testing  will  empha^?'  those  aspects  of  the  CPCI  performance 
which  were  not  verified  by  preliminary  tests.  The  testing  requirements  which 
cannot  be  verified  during  Category  I  test  shall  be  specified  in  paragraph 
4.1.5. 


Qualification  of  this  CPCI  shall  be  accomplished  during  qualification 
testing  to  the  maximum  extent  possible,  as  a  result  of  preliminary  qualifi¬ 
cation  tests  (PQT)  and  formal  qualification  test  (FQT)  conducted  by  the  con¬ 
tractor  and  wi tnessed/veri fied  by  the  procuring  activity. 

4.1.2  Computer  Programming  Test  and  Evaluation 

Programming  test  and  evaluation  which  apply  satisfy  one  or  both  of  the 
following  criteria: 

(1)  They  are  intended  to  be  the  only  source  of  data  to  qualify 
specific  requirements  in  Section  3. 
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(2)  They  must  be  accomplished  as  part  of  an  integrated  test  program 
involving  other  systems/equipment/computer  programs. 

4.1.3  Preliminary  Qualification  Tests 

These  tests  will  directly  support  the  top-down  implementation  and 
verification.  Method  of  verification  shall  be  as  specified  in  Table 
The  following  three  levels  of  qualification  shall  be  performed. 

a.  Unit  Design  Qualifications  shall  apply  to  each  module.  At  this 
level  the  characteristics  which  are  of  primary  interest  are  the  internal 
workings  of  the  module;  logical  flow  control,  numerical  results,  convergence, 
scaling,  and  range. 

b.  Module  Design  Qualifications  shall  apply  to  each  module  after  it 
is  interfaced  with  its  environment.  These  tests  are  basically  interface 
tests;  correct  internal  operations  are  assmed.  The  object  is  to  verify  that 
two  or  more  modules  work  together.  To  comply  with  the  top-down  approach  the 
interfacing  tests  shall  be  sequenced  from  the  top  to  the  bottom. 

c.  System  Design  Qualifications  shall  apply  to  the  completely  assem¬ 
bled  CPCI.  This  level  requires  a  totally  integrated  computer  program.  Such 
testing  discloses  error  due  to  conflicts  introduced  by  data  sharing  convention 
violations,  improper  range  of  input  values,  sequencing  requirements  and  com¬ 
munications  and  control.  The  internal  working  of  the  CPCI  is  of  primary 
concern  with  the  interfaces  of  the  CPCI  with  the  external  environment  deferred 
to  the  Formal  Qualification  Tests. 


4.1.4  Formal  Qualification  Tests  (Specified  in  the  Part  II  Specifications) 

4.1.5  Category  II  Tests  (Specified  in  the  Part  II  Specifications) 


4.2  Verification  Requirements 

This  paragraph  specifies  in  greater  detail  the  method  used  to  verify  the 
individual  requirements  given  in  Table  XLV I  .  (This  Table  cross-references 
tne  sub-paragraphs  of  4.2  which  apply.) 
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TABLE  XLVI 


VERIFICATION  CROSS  -  REFERENCE  INDEX 


METHOD  LEGEND: 


TEST  CATEGORY  LEGEND: 


NA  -  Not  Applicable 


1  - 

Inspection 

A  - 

2  - 

Analysis 

B  - 

3  - 

Demonstration 

C  - 

4  - 

Review  of  Test  Data 

II  - 

Computer  Program  Test  and  Evaluation 
Preliminary  Qualification  Test 
Formal  Qualification  Test 
Category  II  Test 


SECTION  3 
REQUIREMENT 
REFERENCE 

METr.OD 

TEST  CATEGORY 

VERIFICATION 

NA  1  2  3  4 

A  B  C  II 

REQUIREMENT 

3.2 

X 

3.2.1 

X 

3. 2. 1.1 

X 

3. 2. 1.1.1 

X 

X 

4.2.3.C 

3. 2. 1.1. 2 

X 

X  X  X  X 

4.2. 2. e 

4.2. 3. d 

3. 2. 1.1. 3 

X 

X 

4.2. 3. c 

3. 2. 1.2 

X 

3. 2. 1.2.1 

X 

X 

4.2.3.C 

3.2.1 .2.2 

X 

XXX  X 

4. 2. 2.e 

4. 2. 3. f 

3. 2. 1.2. 3 

X 

X 

4.2. 3. c 

3. 2. 1.3 

X 

1 

3. 2. 1.3.1 

X 

X 

4.2.3.C 

3. 2. 1.3. 2 

X 

X  X  X  X 

4. 2.2.e 

4.2.3. f 

- 

4. 2. 2. a 

3. 2. 1.3. 3 

X 

X 

4.2.3.C 

3. 2. 1.4 

X 

3. 2. 1.4.1 

X 

X 

4.2.3.C 

3.2.1 .4.2 

X 

XXX  X 

4. 2.2. a 

—  -  - 

4.2.3.g 
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TABLE  XLVI 


(Continued) 


TABLE  XLVI 


(Continued) 


VERIFICATION  CROSS  REFERENCE  INDEX 


SECTION  3 
REQUIREMENT 
REFERENCE 

METHOD 

TEST  CATEGORY 

1 

VERIFICATION  ■ 
REQUIREMENT 

NA  1  2  3  4 

A  B  C  II 

3.2. 1.9 

X 

3. 2. 1.9.1 

X 

K99H 

4.2.3.C 

t 

3. 2. 1.9. 2 

X 

9  1 

4. 2. 2. a 

4.2.2.C 

4.2. 3. f 

3. 2. 1.9. 3 

4.2. 3. c 

3.2.1.10 

X 

3.2.1.10.1 

X 

4.2.3.C 

3.2.1.10.2 

X 

X 

X 

X 

X 

4. 2. 2. a 

4.2.2.C 

3.2.1.10.3 

1 

4.2.3.C 
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4.2.1  Performance 


The  specified  function  shall  be  verified  with  respect  to  one  of  the 
following  performance  criteria. 

a.  Accuracy  which  may  be  affrcted  by  input  precision,  input  frequency, 
input  accuracy,  or  number  of  iterations 

b.  Execution  time 

c.  Storage  used 

d.  Response  time 

e.  Long  term  degradation 

f.  Stability 

4.2.2  Priori ty/Timinq 

The  specified  function  shall  be  verified  with  respect  to  one  of  the 
following  priori ty/ timing  criteria. 

a.  Interrupt  and  return 

b.  Frequency 

c.  Consistency  in  events 

d.  Order  of  processing 

e.  Scheduling/cancelling  consistency 

f.  Job  stacking 

4.2.3  Interfaces 

The  specified  function  shall  be  verified  with  respect  to  one  of  the 
following  interface  parameters. 

a.  Data  locks 

b.  Range 

c.  Consistency 

d.  Initialization 
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e.  Data  organization 

f.  Human  command/response 

g.  External  procedures 

4.2.4  Logic  Paths 

The  specified  function  shall  be  verified  with  respect  to  the  correct¬ 
ness  of  the  logic  paths  by  exercising  the  computer  program  in  operation. 

4.2.5  Off-Nominal  Condition 

The  specified  function  shall  be  verified  with  respect  to  off-nominal 
conditions  such  as: 

a.  Error  detection 

b.  Error  recovery 

c.  Limitations 
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